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@oraror LABS 


Qrator Labs is a DDOS attack mitigation and BGP security company 


Rate Limiting 


Rate limiting - preventing the frequency of an event from exceeding some 


66066060 


constraint 


Examples: 


@preventing resource starvation 
@load balancing 


QRATOR = Queue 
Rater 


Heavy Hitters 


The Heavy Hitters Problem refers to detecting the most frequent elements of 
the stream 


Applications: 
@traffic analyzing/filtering 
Odetecting anomalies (attacks, soam activities) 


Conditional Rate Limiting 


l.limit rate to a given constant 
2.drop as few unique elements as 


possible 
3.N.B. (2) € 


drop only the most frequent 
elements 


(heavy hitters) 


rate 


keys 


Example 1. SYN Flood. 


sYN-ACK 9 
a | spoofed SYN 2 í 
@attacker initiates a connection ape srw SYN SYN-ACK 
(sends a SYN packet) i paskata svn Vaa ? 
@but does not finalize it PRA secret Ack > 
@the source address can be aaa eae . 
spoofed! JÑ r 
@server has to spend resources || > 
waiting for half-opened 


connections => 


@a legitimate client may be denied 


a connection legitimate 
client 


Example 1. SYN Cookies. 


@SYN Cookie is the most used technique to resist the SYN Flood attack 
@ Drawbacks: 
OTCP options are discarded mm SYN Proxy mode 


| no | | 
We.g. window size! directly to service 


rate 


liny, 


(srcip,dstip) 


=> It is reasonable to reply with a SYN Cookie as rarely as possible 
@=> conditional rate limiting with key (srcip,dstip) 


Example 2. Ingress Services. 


@when protecting /ngress services we are able to see only incoming 
traffic 

@we cannot understand which traffic is legitimate 

@the only way we can protect such a service is rate limiting 


@ internet providers are the most common example 

@an internet provider gives its addresses to its clients 

@only some of them might be under attack 

@it is reasonable to affect as few of the provider’s addresses 


(provider's clients) as possible 
@=> conditional rate limiting with key dstip 


Example 3. MOS vs Packet Loss in Case of VoIP. 


MOS vs. Packet loss rate for AMA (12.2Kb/s) 

Losing even a small part of packets can . 3 “—+— PESO. 
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So, if we are to limit traffic while keeping as 


many users “happy” as possible, we should 2| et or E a a A a | 
Small subset of them a a See ae E | 
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Fig. 6. MOS versus packet loss rate p for AME codec. 


Paper: Voice quality prediction models and their application in VoIP networks a 


NGINX’s limit req 


Limit req zone $binary remote addr zone=perip:10m rate=1r/s; 
limit req zone $server name zone=perserver:10m rate=10r/s; 


Common practice: 


@try to limit total service rate by limiting ip rates (zZone=perip) 
@sometimes this does not help (!), thus total limit is also 
required (zone=perserver). N.B. 
Owhen limiting with zone=perserver, keys are not 
distinguished 
Oit’s not worth increasing the number of perip counters 
(zone size) 


Conditional Rate Limiting VS NGINX’s limit req 


total rate 
does not 
exceed 
the limit 

(legitimate 


total rate 
exceeds 
the limit 
(attack) 


Leaky Bucket Algorithm 


Problem: decrease stream rate down to given 
LIMIT. 


How /eaky bucket works: 
@ Create a virtual queue/buffer (bucket) of 
accepted stream elements 
@Elements from this buffer are removed with 
a fixed rate of LIMIT 
@ The newly obtained element gets either 


eee. Water leaks out of Water spills past 
added to the queue if it is possible (queue bucket with a fixed the overflowing 
IS not full) rate bucket 


@Or dropped 


Value Filter Algorithm. Structure. 


Again, we are to reduce stream rate down to given 
LIMIT 


@Create a counter per each event type 


O rank = (counter / sum of all 
counters) 


@Create a leaky bucket with respect to 
LIMIT 


Osigne / / / J / t of the 
buck (sie, om O to 1) 


occupied 


rate 


keys 


Value Filter Algorithm. How It Works. 


When anew event hits 


@lncrement its counter 
@Compare its rank with the signal 
Oif less, pass and update leaky bucket 


rank 


keys 


Value Filter Algorithm. How It Works. 


When anew event hits 


@lncrement its counter 
@Compare its rank with the signal 
Oif less, pass and update leaky bucket 


rank 


Value Filter Algorithm. Why It Works. 


@if at the moment we pass more than LIMIT 
@the bucket fills up => : 
@its occupancy rate grows => 

@the signal decreases 
@we pass less 


rank 


Value Filter VS Leaky Bucket 


Leaky Bucket Value Filter 
update complexity is O(1) update complexity is O(1) 
limits total rate to a given constant limits total rate to a given constant 


does not distinguish keys 


requires a counter for each key 


Value Filter Algorithm. Drawbacks. 


@Uniform rate distribution 
O=> there are no most frequent 


elements 
Ohow to drop “as few unique as 
possible”? £ 


err keys 
Idea: let’s prioritize the keys we've been d 


passing the most 


Value Filter Algorithm. Drawbacks. 


What if there is not enough memory for a counter per each key (IPv6)? 


Use one counter for several keys: 
@unite keys with the same hash value 
@more specific: counters for subnets, not IPs 


(1) The more precise counters are, the better outcome we get 
=> it is reasonable to have as many counters as possible 


Morris’s Counters 


Counters with value of X updates with probability 
of (2) 


Counte Update Average number Estimated total number 
r Value Probabilit of events needed of events until now 


y for update 
0 1 1 0 
1 1/2 2 1 
2 1/4 4 1+2=3 
3 1/8 8 1+2+4=7 
4 1/16 16 15 
5 1/32 32 31 


Estimated total number of events 
for counter value oP Kis. + 7 X2? s Counting on the fingers of one 
1 hand 


Morris’s Counters 


class Morris: 


def _init (self): o Raw value we store in memory 


self.X=0 


def prob(self): 


return pow(2, -self.X) 
Update probability depends on current 


def update(self): raw value: prob(X) = 2 
if random.random() < self. prob(): 
self.X += 1 


def estimate(self): 
—— = Žž Estimated total number of events for 


return pow(2, self.X) - 1 
raw counter value a*X is 


Morris’s Counters. Main 
Properties. n 


1.n-bit Morris’s counter allows counting up to2 -1 
Oor, counting up to N requires O(log log N) bits 
2.estimate is unbiased: 
Oafter N updates 
avg[est(X)] = N 
3.expected relative error of the estimate is bounded: 
Oafter N updates average relative error 
std[est(X)] / N ~ 1/sqrt(2) 


0.0 0.2 0.4 0.6 0.8 1.0 
#updates 


Morris’s Counters. Mantissa+Exponent Extension. 


Splitting counters bits into two parts: exponent, giving Oo 102121001 


update probability, and mantissa 


S 
T 
exponent mantissa 


Counte Update Average number of Estimated total 
r Value Probabili events needed for number of events 
update until now 
1 0 D 
l l 0 0 0 0 0 0.0 0 
1 1+1=2 > - y v 
here exponent gives mantissa changes 
i as update probability of from 0 to 32 
1 JLLS 7 (4)*0=1 
2 32*1=32 
Oo 0 1 O 0 Od OQ. 0 
2 32*1+31*2=94 here update and again we need 32 
probability is successful updates for 
4 32*1+32*2=96 1/2 further probability reduction 
update probability 
a a 1/4 
8 32*(1+2+4)=224 > update probability 1/8 


Morris’s Counters. Mantissa+Exponent Extension. 


08 average relative error 


Why is this even 
useful? = NOs 


—— morris(exp=5,mant=3) 
—— morris(exp=3,mant=5) 


0.0 0.2 0.4 0.6 0.8 1.0 
#updates leo 
@maximal accountable number of events decreases 
@but the relative error of the estimate gets better! 


Summary 


1.Conditional Rate Limiting 
2.Value Filter = Leaky Bucket + Counters 
Owhat are keys? 
Midstip 
Mi (srcip,dstip) 
Ocounters 
Mitaking into account temporary nature of rates 
Musing some tricks to save memory 
Ovolume of the bucket (burst) affects how quickly the algorithm 
reacts to changes in the flow pattern 
3.Morris’s Counters 
©OMantissa+Exponent Extension 
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